Transfer the MCP Server project template from extensions to aspnetcore#66260
Open
jeffhandley wants to merge 3 commits intodotnet:mainfrom
Open
Transfer the MCP Server project template from extensions to aspnetcore#66260jeffhandley wants to merge 3 commits intodotnet:mainfrom
jeffhandley wants to merge 3 commits intodotnet:mainfrom
Conversation
Port the mcpserver template from dotnet/extensions into dotnet/aspnetcore as a new Microsoft.McpServer.ProjectTemplates template package. - Create McpServer.ProjectTemplates/ with template content (local/remote transports) - Add .csproj-in files with version placeholders for GenerateContent.targets - Add ModelContextProtocol/ModelContextProtocol.AspNetCore version tracking - Add McpServerTemplateTest covering local/remote, self-contained, and AOT flavors - Wire into AspNetCore.slnx and ProjectTemplates.slnf Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace modelcontextprotocol.github.io/csharp-sdk with csharp.sdk.modelcontextprotocol.io/ in both local and remote transport README templates. Remove references to the template and MCP Server usage being preview. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Split parameterized theories into individual ConditionalFact methods - Replace stale global AOT skip with SkipOnHelix for specific queues - Add template-baselines.json entries for local and remote transport - Add VerifyLaunchSettings for remote transport - Add run verification for remote transport (built + published) - Default args parameter to null in core method - Add skipRestore symbol and --no-restore CLI mapping to template config - Add NuGet restore post-action to template - Register McpServer.ProjectTemplates in TemplatePackageInstaller - Add .gitignore for generated .csproj files Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
bot
added
the
area-mvc
Contributor
There was a problem hiding this comment.
Pull request overview
This PR brings the mcpserver project template into the aspnetcore repo so it can participate in the existing template-pack build/test infrastructure and dependency flow toward eventually bundling it in the .NET SDK.
Changes:
- Adds a new template pack project (
Microsoft.McpServer.ProjectTemplates) containing local (stdio) and remote (HTTP) MCP server template variants. - Wires the new template into the ProjectTemplates solution(s) and template test infrastructure (baselines + new E2E test).
- Introduces version plumbing for ModelContextProtocol packages and updates build exclusions for generated template project files.
Reviewed changes
Copilot reviewed 26 out of 27 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/ProjectTemplates/test/Templates.Tests/Templates.Tests.csproj | Adds content + project reference so template tests can access/build the new template pack. |
| src/ProjectTemplates/test/Templates.Tests/template-baselines.json | Adds baselines for mcpserver local/remote variants. |
| src/ProjectTemplates/test/Templates.Tests/McpServerTemplateTest.cs | Adds E2E coverage for creating/publishing/running the new template variants (including AOT scenarios). |
| src/ProjectTemplates/Shared/TemplatePackageInstaller.cs | Includes the new template pack in the list of template packages installed for tests and updates expected package count. |
| src/ProjectTemplates/ProjectTemplates.slnf | Includes the new template pack project in the ProjectTemplates solution filter. |
| src/ProjectTemplates/McpServer.ProjectTemplates/Microsoft.McpServer.ProjectTemplates.csproj | New template pack project that generates the variant-specific .csproj files from .csproj.in inputs. |
| src/ProjectTemplates/McpServer.ProjectTemplates/*.csproj.in | Defines generated project files for local/remote template variants with optional self-contained / AOT publishing settings. |
| src/ProjectTemplates/McpServer.ProjectTemplates/content/** | Adds the actual template content (template.json, host configs, README/Program files, launchSettings/http file, tool sample, icon). |
| src/ProjectTemplates/McpServer.ProjectTemplates/.gitignore | Ignores generated project files emitted during template-pack build. |
| eng/Versions.props | Adds ModelContextProtocol package version properties used during template content generation. |
| eng/Dependencies.props | Adds ModelContextProtocol packages to latest-package tracking. |
| eng/Build.props | Excludes generated template project files under the new template pack from general repo globbing. |
| AspNetCore.slnx | Adds the new template pack project to the main solution. |
Comment on lines
+117
to
+122
| using (var aspNetProcess = project.StartPublishedProjectAsync(hasListeningUri: false, usePublishedAppHost: nativeAot)) | ||
| { | ||
| Assert.False( | ||
| aspNetProcess.Process.HasExited, | ||
| ErrorMessages.GetFailedProcessMessageOrEmpty("Run published project", project, aspNetProcess.Process)); | ||
| } |
There was a problem hiding this comment.
The template defaults to self-contained + single-file publish, but this test only uses usePublishedAppHost when nativeAot is enabled. That means the default self-contained publish path is being executed via dotnet exec <dll> instead of the app host, so we’re not actually validating that the published single-file/self-contained output runs. Consider setting usePublishedAppHost based on whether the template publish is self-contained (in addition to native AOT).
Member
Author
There was a problem hiding this comment.
@copilot apply changes based on this feedback
Comment on lines
+133
to
+138
| using (var aspNetProcess = project.StartPublishedProjectAsync(hasListeningUri: true, usePublishedAppHost: nativeAot)) | ||
| { | ||
| Assert.False( | ||
| aspNetProcess.Process.HasExited, | ||
| ErrorMessages.GetFailedProcessMessageOrEmpty("Run published project", project, aspNetProcess.Process)); | ||
| } |
There was a problem hiding this comment.
Same as above: the remote transport path publishes self-contained by default, but the published run uses usePublishedAppHost: nativeAot only. Running the published app via the app host when self-contained would better validate the template’s default publish configuration (self-contained/single-file).
This was referenced Apr 10, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ultimate goal is to include the
mcpserverproject template in the .NET SDK. To accomplish this, we will:The aspnetcore repo is a good fit for this because:
mcpservertemplate offers a "remote" transport option that uses ModelContextProtocol.AspNetCore and the ASP.NET Core ref packSee also: Add Microsoft.McpServer.ProjectTemplates as BundledTemplate (dotnet/sdk#53802)